libxl: Remove libxl_tmem_destroy and associated xl command
authorIan Campbell <ian.campbell@citrix.com>
Mon, 16 Apr 2012 15:00:47 +0000 (16:00 +0100)
committerIan Campbell <ian.campbell@citrix.com>
Mon, 16 Apr 2012 15:00:47 +0000 (16:00 +0100)
commite601453ce6046956507df3efab03a9f767517ea5
tree6c566b8d8bdb71a1756321f8953157e5e68bc0c4
parent663448101e80c738e486e41b4d40d38a8b436123
libxl: Remove libxl_tmem_destroy and associated xl command

Dan Magenheimer explains in <4c2f7fca-dda2-4598-aaab-3a6a3fe532cd@default>:

I think the tmem_destroy functionality pre-dates the
existence of tmem "freeable" memory* and was a way for
a toolset to force the hypervisor to free up the hypervisor
memory used by some or all ephemeral tmem pools.  Once the
tmem allocation/free process was directly linked into
alloc_heap_pages() in the hypervisor (see call to
tmem_relinquish_pages()), this forcing function was
no longer needed.

So, bottom line, I *think* it can be ripped out, or at least
for now removed from the definition of the stable xl API/UI.
The libxl.c routine libxl_tmem_destroy() could also be
removed if you like, but I guess I'd prefer to leave the
lower level droppings in xc.c and in the hypervisor in case
I am misremembering.

Accordingly remove this interface from libxl and xl but don't touch libxc or
the hypervisor.

This is the only libxl_tmem_* function which might potentially have required
conversion to be asynchronous and which therefore might have been a potential
API stability concern.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
docs/man/xl.pod.1
tools/libxl/libxl.c
tools/libxl/libxl.h
tools/libxl/xl.h
tools/libxl/xl_cmdimpl.c
tools/libxl/xl_cmdtable.c